-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Update mupen64plus to latest upstream version #4117
base: master
Are you sure you want to change the base?
Conversation
this is such a great idea
reading systembus currently crashing the emulator, might need to look into that
TODO: - allow enabling/disabling debugger dynamically, it really doesn't need to be on permanently, requires a mupen-side change tho - provide registers - figure out why size of mupen went +800kb, is it just -lopcodes, -lintl, -liberty? - debugger (trace and debugger itself) doesn't work in dynarec, notify or unregister services accordingly - figure out why cached interpreter has <60 fps
see TASEmulators#3220, probably fixes some controller and SDL exceptions i've been observing previously
I feel I should let @Wyst3r know about this. |
also rebuilt some other stuff from newer source it... doesn't really work yet
The latest commit adds linux binaries which "work", as in everything loads, but I've experienced freezing after 1-100 frames. It's not a crash, just an unresponsiveness forcing me to close the program. I have no idea how to debug this except by adding dozens of console.writelines and trying to narrow down the place it's getting stuck at. |
still same issue as before though
Just for the sake of re-documenting it here and not like somewhere in the Discord (and it is the first todo point). better gln64 is a high recommended from Mupen64-rr-lua mainly for it having low hardware requirements and better to TAS with. The only caveat against it from what I can tell is that it's HLE and not LLE and some glitches with certain titles (which some of the plugins already in Hawk has those issues). So in other words it would be a suitable replacement to Rice (so lowest of the low). And whilst porting it, it's probably beneficial to disable the texture settings (technically you can hide everything, and make it just the plugin, but some people might benefit from disabling fog). |
Linux can be fixed to work with all currently checked in binaries by applying the following diff: diff --git a/Assets/EmuHawkMono.sh b/Assets/EmuHawkMono.sh
index 7ca69f6ea..e695450ac 100755
--- a/Assets/EmuHawkMono.sh
+++ b/Assets/EmuHawkMono.sh
@@ -18,6 +18,7 @@ fi
export LD_LIBRARY_PATH="$PWD/dll:$PWD:$libpath"
export MONO_CRASH_NOFILE=1
export MONO_WINFORMS_XIM_STYLE=disabled # see https://bugzilla.xamarin.com/show_bug.cgi?id=28047#c9
+export MONO_THREADS_SUSPEND=preemptive
if [ "$1" = "--mono-no-redirect" ]; then
# printf "(passing --mono-no-redirect is no longer necessary)\n" #TODO uncomment later
shift Looking at the documentation, it looks like this might be an actual mono bug (maybe mono/mono#14084 ?). Either |
Could you post the full stdout/stderr output? There should be some logging about plugins in the beginning. |
GLideN64
angrylion-plus
|
Hmm, those logs look proper, nothing out of the ordinary there. Note that for angrylion-plus, the |
Oh, that fixes it, now I can get in-game and it's almost playable (mostly stable 50 fps). |
Looking at how that works, it does somewhat make sense. You have a pure native thread being created (in this case the "render thread"), without the runtime having any knowledge of them (since they weren't made with managed APIs). As such, it doesn't really know of such a thread needing to be suspended for GC purposes. This is all fine, as long as that thread remains in unmanaged land, and thus doesn't touch managed state. Once it tries to come back to managed land (via a callback), things go very poorly. |
Work in progress update of the mupen64plus core to the latest version. This would ideally improve compatibility and increase accuracy and be a real-time playable alternative to the existing ares64 core.
There's a couple of known TODOs that need to be resolved:
integrate mupen core and plugin sources and build in the bizhawk repo; I currently build from a fork that is not checked in to bizhawk (https://github.com/Morilli/mupen64plus-core/tree/bizhawk)<-- done, TODO build instructions / automatic build script for core and all pluginsIDebuggable
functionality is missing, mainly because registers aren't implemented. Registers not being implemented also affectsITraceable
impl (why is that required but only exposed inIDebuggable
... whatever)The diff should be relatively clean, the commit history isn't. Best to look at the full diff instead of individual commits. Some dlls may be missing from Assets, that will need to be fixed once plugins and compile commands are finalized.